MASSACHUSETTS INSTITUTE OF TECilMOLQCY 
A * I > LA B- 


Artificial Intelligence 

Memo No- 210 December 1970 


A USER'S GUIDE TD THE A * I. GROUP L1SCOM LISP COMPILER: 

INTERIM REPORT 


Jeffrey P + Golden, 


Worh reported herein wag supported by Project me and the 
Artificial Intelligence Labors tory r M-l.T. research programs 
sponsored by the Advanced Research Projects Agency of the 
Department of Defense under Office of Haval Research contracts 
number NGOO14-7O-A-0362-0001 and -0002. 

Reproduction of thig document, in whole or in part, is per¬ 
mitted for any purpose of the United States Government, 


LIS COM &age 1 


Table of Contents 


page 


I* Introduction 

IL Operation ~ C^pl Ling 

A.„ LISCQM's top-level functions 

f, COMF1LE 
Z* Cf 

3 . COMPILE 

4 . CMP, CM 


B. Handy functions, global variables, 
and notes 

(a) Functions 

1. DECLARE 

2 . GENPREFIX 

5. initialise 

(b) Global variables - switches 

1, ^INITIAL 

2, *SYM6 OLS 

3, *GRIND 

4 , *R£D EF 

5, ^CLOSED, *ARIIH, *MLf££LED 

6 , *DEBUG 


(c> Global variables - other 
I* UNDFUNS 
£* NEWSp£CYARS 

3, GENLIST 

4 , TAG CNT 

5, FUNNAME 


idj Notes on compil Tog 
? . Errors 

2 . Generated functions 
3* r-tvpe functions and SPECIALS 
4 , Redefining system functions 


IHi Operation 


l 

4 

4 


7 

7 


t 


n 


j j 


Formatting 


14 


LTSCOM page 3 


I. Introduction 

The LISCGM version of the A. I, Group PDP/fitfi?} L [ sp 
compiler is 3 descendant of the original Greenl}latt“Nelson 
compiler, ant! is a friendly s i b! i ng to the COMPLR versioh 
maintained by Jon L. White* The compiler operates In two passes 
to translate LTSP code into LAP code. Tine first pass performs a 
general study of the S-expression function definition which is 
to be compiled, producing as output a modified ii-express i on and 
various * tab las'* attached to free variables* The second pass 
does the actual comp] Hat I on (generation of assembly code), 
making use of the transformations performed and the information 
gathered by the first pass* 

The LiSCQM version of the compiler is being used as a 
vehicle for the Implementation of 'fast arithmetic' in LISP. 

This work Is being done under the auspices of the MATHIAS 
project of the A*l, Laboratory. The early stages of the 
compiler implementation were handled by W. Dlffle, and the work 
has been continued by the present author,, Corresponding changes 
to the LISP system were implemented by W. A* Martin and Jon L, 
White. The Idea is to use user declarations of fixed-point and 
floating-point variables and functions - as to the value they 
return, as well as other mechanisms more convenient in certain 
situations (to be described at a later date), to enable the 
open-compilation of the LISP arithmetic functions* At the 
present date, the conversion of the first pass of the compiler 
to handle 'fast arithmetic' has been completed. The conversion 
of the second pass Es now under way. Also, some improvement In 
the output code and many bugs in the compiler were removed as a 
joint effort of the present author and Jon L. White* 

Every attempt has been made to make the L15C0M and C0MPLR 
versions compatible in the sense that a user need not make any 
changes to his flte to switch from one compiler to the other* 
There are, however, differences In some pf the top level 
functions through which the user corresponds with the compilers, 
in the format of the LAP outputted, end perhaps also, in the 
speed of operation of the compilers, in the relative 
efficiencies of some of the LAP code, and In convenience to the 
user tn terms of warning and error messages, etc* The usage 
conventions of the LISGOM version ere described In the following 
section* The only descriptions of the usage of the COMPLY 
version available at the present date are found in A.I. Memo 
11&A ( P3P.-6 LISP Revised )* p* 5 and A, I* Memo 1VQ ( An Inter inn 
L15P User^s Guide). Annaiud.Lx Jt, both written by J* L, White, 

Some discussion relating to the user's Interaction with the 
compilers (e*g* relating to DECLARE) may be found in A*I* Memo 
?90, p* 34 ff* A description of the actual operation of the 
compiler as of June 7969, especially the LIS COM version, written 
by W, Diffie, is available from the present author* 
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II* Operation 

One may load in the LISCQM eompi ler by typing at DDT 
"LISCDMfrt' or "i IISCQM ;og)". Since the LISCQM version uses the 
formattinn functions of the GRIND package (see A.I* Memo 190, 
Appendix F) * one may use LISCOM for both compiling and 
formatting S-expressEons, although the Latter Is surely 
Inconvenient when compared; to Loading in the file GRIND LISR on 
device COM* In any event, both features of LISCOM are described 
below* let us note here, that the features described below are 
subject to change (hopefully with notice) 1 * 

Comp] Jing 

A. LI-SCDM's top- level functions: 

These functions are all FSUBRs (unLess they take no 
argument In which case they happen to be SUBRs). 

!* COMF1LE? COMFILE Es the major function which enables 
the user to translate one or more files of LISP code (these 
files are called the "‘source files'*, and are denoted here as 
fnl fn£, gnl gn£, etc*} into a single fTle of LAP code ■(this 
file is called the 'target file' and is denoted, here as 
tnJ tn2K 

A file to be compiled may contain function definitions (via 
DEFPROP or DEFUN5 to be compiled, MACRO-definEtions to be 
expanded, LAP code, declarations to the compiler (via DECLARE * 
described below), comments Ivla COMMENT), and any other random 
5-express Ions * All but function definitions via DEEPftDP or 
DEFUW, MACRD-def \ nitlons, and declarations via DECLARE are 
simply passed on through to the target file "untouched' (except 
see the discussion of the *GRIND switch below). MACRO- 
def1nitlonj are expanded In Pass I and take priority over (i*e. 
Can be used to redefine) system-defined functions, Since MACRO- 
definitions are placed on the property list of the MACRP-nane, a 
conflict wilt occur (of which the user will be informed) if a 
user MACRO has the same name as a compiler function and Tf the 
MACRO is called from within other (or the same) MACRO- 
definitions* IThe LISP system may be hacked later on to prevent 
this rare conflict from occurring by "prefixing" a "file name' 
to each function name). Also, noting the description of DECLARE 
below, if DECLARE is used carelessly (e*g* foolishly modifying 
global variables Intended solely for the compiler's Internal 
use), trouble may ensue* No other conflicts between user names 
I for variables and functions) and compiler names can occur* 
Finally, Let us note here that it is Intended that the compiler 
be able to compile (almost) any function that runs 
interpretsve ly and can be compiled. If any user runs into 
difficulties with the compiler, he should see the author* 
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COMPILE takes a list of n >= ft filenames t v j i t h -device and 
sname spedfleet Ions if desired - the usual default options are 
available) as argument* There are three special cases: n = 0* 
n = J* and n >*= £, 

(a) n " 0; Typing (COMPILE} to LI 3COM is coirip lately 
analogous to typing (CMFl) to CQMPLR* This gives the user 
Control over the compilation process. An example of this use* 
beginning here with the loading operation* is as follows: The 
user is talking to DDT* which has typed "e" at him. 

*** LISC-OMCk" \ " (that which the system types at the 

' user is enclosed In single 

quotes * ) 

"LISCOM COMPILER (etc.)" 

(UREAD fnl fn?) (the file to be compiled) 

^(device shame)" 

(UWR1TE 3 

"(device sname)" 

(COMPILE) 

"COMF1LER-LISTENING' 

fR [W 15 (I/O switches are set as desired) 

, * * (the compilation) 

"(func * ttEXFR)" (the E*FR "func" has been compiled) 


"FINISHED' (the compilation has been 

completed) 

(UFILE tnl tnj)^ 

"(device sname)" 

Many variations on the above are possible* e.g. outputting to 
the line-printer, rather than to the disk; or defining functions 
on- Mne and compiling them. 

The n >“ I cases are the more usual ones. Here* the 
compiler handles the entire compilation process for the user* 
including the setting of I/O switches and filing (UWRITEing* 

UREAD Eng, and UFILETng). 

(b) n ■ I: In this case* CQMFILE takes a list of one 
source fE l e- name 

(fnJ fnZ dev sname) 

as argument* and it outputs the compiled file as 
(fnl LAP dev sname)* 

("dev sname" perhaps being specified by default* of course,) An 
example call is 

(COMPILE (POP LISP)). 
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In this case rf only one iource file can be translated into a 
terset fjle. The INITIALISE function described he low is 
relevant here, 

(c) n >=■= 2: In this case, COMPILE takes a Hst of n ~> u 2 
fiie-names as argument; the first file-name Is taken to be the 
target file and the remaining n - J filenames are source flies. 
The files are picked up in I efE-to-rlght order. In this manner, 
one or more source fl Les may be translated Into a single target 
file. A sample ca l I Is 

(COMPILE (OUT COMP) (FOO LISPI) (GOO LISP'S US K. JJ)). 

When n >= l, the ^INITIAL switch (global variable) described 
below may be relevant. 

2, CF: The function CF Is available as a convenience for 
those users who need to or wish to compile the seme file 
sequence twice. The file specifications made In the last call to 
COMPILE with n >■ I are preserved on the property list of the 
atom TRY, so that one need only 'evat - (CF) (for £ofnpl Ie £3 le) 
in order to repeat that call to COMPILE. 

3* COMF1L£; COMPILE Es used to compile or recompile 
individual functions, perhaps only in order to investigate the 
code being produced, COMPILE takes as argument a list of the 
functions (i.e, their names) to be compiled, I.e, 

{COMPILE fun I funf ... funU. 

COMPILE assumes that the S-expresston definitions for the 
functions have been loaded in already by the user. In 
formatting, COMPILE uses the line-length (LINED of the device 
(console) at which the user 'is togged-in, as opposed to COMPILE 
which uses the line* length of the line printer (actually £0. and 
not 1 20.) This nay be changed by the user by CETQEng LINEL to 
PAGEWIDTH, When recompiling, the function GENPREF1X discussed 
bfilow is Useful, 

4. CMP, CK: These functions are useful only for 
investigating the code produced by the compiler. CMP takes as 
argument a LAMBDA expression to be compiled, i.e* 

(CMP (LAMBDA *,,)), 

which Is compiled as a SUfift called TRY* I.e. CMP combines in 
one step a 

(DEFPROP TRY (LAMBDA „ , .) EX PR) 

and 

(COMPILE TRY)* 

CM (for £cmpi le Jiame), which takes nc argument, is used to 
repeat the last call to COMPILE, through the use of the global 
variable TUNNAME, mentioned below. 
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0, Handy functions, global variables, and notes: 

The following is a description of functions and global 
variables available in the compiler to aid In the compilation 
process: 

{a) Functions 

J. DECLARE: DECLARE, an FSUBR, Is an all-purpose function 
used in handling declarations of variables (via the functions 
SPECIAL and UNSPECIAL) and functions (via *FEXPR and ^LEXPR) as 
well as In causing evaluations to take place immediately* 

Indeed, 

DECLARE lexpr.J - KAPC [(FUNCTION EYAL) (CDR expr*U r 
(Thus, one need not use DECLARE upon having loaded In the 
compiler, before initiating the compilation process*} DECLARE 
will also enable the user to inform the compiler as to how he 
wishes "fast arithmetic' to be done, when such Is available - a 
full description will be given at that time* DECLARE is treated 
by the LISP interpreter just as is COMMENT; however, in the 
compiler It takes effect whether used at the top level or in a 
function definition* DECLARE or an alternative must be used to 
Inform the compiler 

U) via the compiler function SPECIAL of variables which 
appear free in some function(s) in the file or of those which 
the user would Ilka to refer to by name later on* The compiler 
and the user may access these variables via the 'SPECIAL cell' 
on their property List* Much will be said of the former use In 
Eater sections. The function UN$PECIAL Is used to remove the 
SPECIAL declaration* 

(2) vie the compiler functions *FEXPR and *LEXPR, 
respectively, of FEXPfts and UExPRs CKe* EXPRs with atomic, noo- 
NIL LAMB&A-" lists) which are called within function definitions 
before they themselves appear (are defined} In the file, (the 
•default option for such 'undefined" functions is that they ere 
of EXPR-type, and an error message win, be printed out if this 
is not done), if indeed they appear there at all* 

DECLARE is also used in SfTQing the 'user-accessible' global 
variables described below. Thus, $ sample call is 

{DECLARE (SPECIAL var) var£) (*FEXPR funD (SETQ *G RIND 3) 
(G£NPREFIX H)>* 

(SPECIAL, UNSPECIAL, *EXPR, *FEXPR, *LEXPR, and GEN PREFIX are 
all FSUBAs defined by the compiler.} 

£* GENPREFIX: GENPREFIX is useful when recompiling 
Individual functions to be placed In a file alongside other LAP- 
code or in compiling several files at different times which are 
later to be assembled Into one system* GEN PREFIX is used to 
avoid conflicts between tags and between GENSYHs (generated 
symbols) which are used by the compiler for generated functions 
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(see the 'Notes'* section below), (Tags are total to the LAP 
function in which they appear,, but only one occurrence of each 
tag may appear In a DDT symbol table)* The syntax Is 
CGEHPREFIX atom) 

and the atom, e.g, BAR, is used ( >) to prefix a GENSYM, e,g. 
Converting GLiJJS to BAR0)05 In Che case of generated function 
names} and (2) as the prefix to an integer (counter} TAGCUT In 
the case of tags. See the discussion of the global variables 
GENLIST and TAGCUT below, A one-character atom is usually used, 
and indeed the generated atom (BAR0J05 here} may not have more 
than 6 characters If it Is to be placed in a DDT symbol table, 
■GENPREFIX also resets TAGCNT (see later) to fl, {It is hoped 
that some day functions associated with GEHSYMmlng will be added 
to the LISP system to replace the need for GENPREFIX as used for 
generated functions,) 

3, INITIALISE: INITIALISE, a SUBR, Is useful when 
compiling more then one file with a single loading of the 
compiler, INITIALISE takes as argument I, 2, or 3 which 
indicates its mode: If arg = l, INITIALIZE removes all SPECIALS 
from the OBLIST, This is obviously a less efficient alternative 
to declaring all of one's SPECIAL variables UNSPECIAL at the end 
of the file. If arg = 2, INITIALIZE removes all *EXPR, ftFEXPR, 
*LEXPR, and MACRO properties from the GBLIST, except for those 
*EXPR flags used by the compiler. If arg = 3, INITIALIZE takes 
both of the actions described above under args l and £. Thus 
INITIALIZE can be used to obtain a clean environment for 
compiling the next file, without the necessity of reloading the 
compiler. When using COMPILE wTth n > l t IWlTIALIECEJatI on is 
accomplished through the setting of the ^INITIAL switch, 
described below. 


(bj Global variables - switches; 

Some of the user-accessible global variables In the 
compiler are switches which may be set {e*g„ via DECLARE) to T 
or NIL, or to an Integer, as the case may be. To Indicate whEch 
global variables are switches, * is used as the first character 
of their names, 

I, ^INITIAL; As mentioned above, when using COMPILE with 
n > 2, INITIALIZE may be called between each paTr of files 
inputted for compilation by simply setting ^INITIAL 
appropriately, ^INITIAL is the argument to INITIALIZE, and the 
actions caused by setting ^INITIAL to 1,2, or 3 were described 
above. The default setting is 0, In which case INITIALIZE Is 
not called. 
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2* ^SYMBOLS! Setting *$YMBOLS to T causes fSYMBOLS T} 
followed by a tag to be 1 inserted Into the LA?-code immediately 
after the (LAP funname type) pseudo-instruction for each 
function then compiled* The teg Is useful En cases where two 
function names begin with the same 6 characters, since these 
Cannot be differentiated within the DDT symbol table* for an 
explanation of (SYMBOLS T-or-Hli,) see A.I. Memo 198, p* 1-5* The 
■default setting of ^SYMBOLS is NIL* 

3* a-GRIND: Any S-ekpresslon (including fiACRQ-def [ni t ions ) 
in the source file that is not a function definition is output 
'as is' las described below) Into the target file, (Even 
DECLARES are output, so that If the user wishes to Investigate 
his LAP code, he can easily check out the compiling environment 
as to SPECIALS# UNSPECIALs, etc*} wGRIHD gives the user control 
over the manner in which both the random S-expresslons mentioned 
above and the LAP-code Is output# as follows: 

*GRIND » 0 lthe default setting}: everything is 

formatted ('ground.'), 

=1: only the LAP-code Is ground, 

* only the random S-expressions are ground* 

= 3i nothing is ground. 

Furthermore, If *GRlFiD = 0 qr I# the compiler outputs a form* 
feed after every 53 lines (or so - if aQRIHD - 1}; if aGRINC = £ 
or 5, the compl ler outputs a form-feed after the LAP-code for 
each complied function* Whereas formatting makes for much more 
aesthetic and readable output, it is time-consuming and the user 
may prefer not to grind out e.g* his LAP-code* 

4, aREDEF: When set to T# *RED£P tells the user about 
functions which are defined more than once In the s&urce files. 
This may be useful when compiling more than, one source file with 
one Loading of the compiler.* with the intention of assembling 
these fELes into one file or system* Users who Intend to 
compile the same file more than once with one compiler loading# 
e,£* to take advantage of the compiler's declaring as SPECIAL 
undeclared free variables, should not have aREDEF set to T on 
the first go-round* The default setting of *REDEF Is NIL. 

5* ^CLOSED, aARITH# *MU££LED: These switches have to do 
with fastestithmetlc compiling, end hence, are not yet of 
interest* It should be pointed out, though, that setting ^CLOSED 
to T, which in fact Is Its current default setting, causes the 
compiler not to attempt to do any fast-arithmetic compiling, 
which Ts now the intention. 
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6* *D£EUQ: As the compiler is loquacious In its error and 
warning messages (see section (d) I* below), several LISP users 
have used the compiler for debugging purposes - seeking out 
typing errors/ etc. For this reason/ a special faster debugging 
mode> which Is entered by setting VlDEEIjG to T, has been added to 
the compiler. In which no LAP code Is generated, no output file 
Is opened, and in fact, the compiler does not go through its 
second pass at all* The lists U.NDFUN5 and ■MEWSPECVARJ (see 
below) are stTll maintained, The only warning message which is 
not issued as that for undefined GO tags (see be low)* One may 
use COMPILE In the manner described above, (For n >= 2 , the 
target file should be H1L), The default setting of *DEBU& Ts 
NIL. 
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{c) Global variables * others 

I. UNDFUNSs Upon completing the compilation for each call 
to COMPILE, the compiler prints, out the elements of the list 
UNDFUNS, These are the names of user functions which though 
celled within the source file(s), were not defined there. The 
functions appear in UMDFUNS En the order of their first calL 
The user can ask; for this list to be printed again (or for the 
first time in the case of COMPILE) by availing UNDFUNS. 

Z* NEVISPEGVA^&J WEWSPECVARS Is a list of all those 
variables seen since the last tall to COMPILE or COMPILE which 
appeared fret in some function but were not declared SPECIAL, 
These variables are made SPECIAL by the compiler. To have this 
list printed out, the user Jsiay eva i NEWSPECVARS. 

3. GENLISTj Eval11ng (GENFREflX atom) as discussed above, 
say atom * BAR, sets GENLI3T to the list (6 A R) * Thus, the 
same result can be had by setting GENLIST accordingly, except 
that GENPREFIX also resets TAGCNT to 0 , The default setting of 
GENLI5T Is (G). 

4. TAGCNT: Tags generated by the compiler are obtained by 
(MAKNAM (APPEND GENLIST 

(EXPLODE (SETQ TAGCF5T (ADD I TAGCNT)?))), 
Upon loading in the compiler, TAGCNT Is set to 0 , The user may 
set TAGCNT to some positive Integer If he wishes, 

5. FUNNAMEs FUNNAME Is set by COMPILE and COMPILE to the 
name of the current function being compiled, or to the last such 
function If the compiler has just completed comp fling a 
function. Thus, if an error occurs while compiling, availing 
FUNNAME enables the user to determine the name of the function 
being compiled. 


(d) Notes on compilings 

1, Errors which causa the compiler to stop, fall Into 
three general categories: (!) breaks: which are genera Ely 
caused by compiler errors, (£) data^errors: which the compiler 
believes to be caused by errors within the user^s function 
definitions, and (3) errors in data or due to the compiler whEch 
the compiler does not check for, but whEch eventually lead to 
LIS? errors. We will address ourselves here only to the first 
two categories in the hope that those of the third category wilt 
rarely If ever occur. 

In the case of (i) or (£), the compiler enters a read-evat- 
print loop which Es useful in debugging the comp 1 Ear or In 
investigating further the existing state of affairs. To exft 
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from this loop, the user usually types ^ or fl"; of course, th 
the Intention of notifying the author in ease of a compiler 
error* The user may also wish to type §P_ or ($ ■ <att* 

mode>, ^ = <space>J to proceed* In the case of (I) compiler 
errors, In which case the compiler prints out frBREAK* followed 
by the error message, typing either +P_ or SX_ will cause the 
compt ler to recommence compiling wl th the next function In the 
file* (In this case only, the compiler may have output some 
spurious LAP“code,) In the case of {£) data-errors, the 
compiler prints out either *NRDATAEftR*- Dr frftDATAERR* followed by 
the error message. In the case of •a.NRDATAJEftR* or "non- 
recoverable data error", typing or t>C_ again causes the 
coitipi Ler to go on to the next function* In the case of 
ttRPATAERR* or "recoverable data error", typing iP_ causes the 
compiler to continue compiling the same function, perhaps after 
making some reasonable adjustment if necessary; while typing $X_ 
again causes the compiler to go on to the next function* The 
Intention Is to give the user the option of continuing with the 
same function with the possibility that the compiler will 
discover more data-errors therein; or indeed, the compiler may 
correct the error, as described below. The user may In any 
event decide to recompile the function^or the file Later on. At 
present, there are only four cases of "recoverable date-errors": 

tf) The compiler encounters an FEXPR or LE>PR definition, 
having previously compiled the function as an EXPR, Typing $P_, 
will cause the compiler to continue compiling, taking the 
function to have f-type or L-type, respectively, from now on. 

(£) The user has a MACRO-defInitIon with the sene name as a 
compiler function* The user wilt lose only In the situation 
described above (l.e* the MACRO Is called wlthTn other (or the 
same) MACR0' p def i n i ticns . ) If this is not the case, the user may 
type , and the compiler will continue, making certain that a 
conflict will not occur* 

(5) The user calls a system function with the wrong number of 
arguments* The user may type SP_ , causing the compiler to 
continue as follows: If he called the function with too few 
arguments, the compiler appends tilts for each of the remaining 
arguments* If he called the function with too many arguments, 
the compiler makes no change in the case of closed-compf led 
functions* The more commonly used open-compiled functions pull 
off only as many arguments as they need* Later, the user may 
wish to edit the LAP-code for this function or recompile It. 

(4) A RETURN Is used not In the context of a PROG* Typing $P_ 
w|Lt cause the compiler to strip off the RETURN, i.e* convert 
(RETURN erg) to arg, and continue* 

Other possible errors In user code may simply cause the 
compiler to print out a warning message and go on. This does 
not mean that these situations are not really errors* for 
example, the compiler may complain that it has encountered a 
free variable which has net been declared, which it then makes 
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SPECIAL, If this variable has been used bound in previous 
functions and the user Intends for these occurrences to mean the 
same variable, then a ml seonspl Lation has occurred* Warning 
messages are also given In ease of unused PROG or LAMBDA 
variables - bound variables which are not declared SPECIAL and 
which are not evaluated within that PROG or LAMBDA; undefined GO 
tags, In which case the compiler simply outputs a JRST (jump) to 
the end of the LAP^code for the PROG; etc* These may all 
signify errors* 

2* There are two circumstances which cause the compiler to 
compile code out of content, I*e, to extract LISP code from a 
function definition and to compile it as a generated functions 
U3 Lambda funargs: any occurrence of 
{FUNCTION (LAMBDA * . *)> 

En code causes the LAMBDA expression to Be complied as a 
separate function* 

(£) Any call to ERR$ET of the form 
(ERftSET argf are?) 

(ERASE! arg?) 

in which argl is neither an atom nor a list of a single atom 
Cl*e+ a function call with no arguments) causes argl to be 
compiled as a separate function of the form 
(LAMBDA MIL ar E l>* 

The latter circumstance as a cause for compilation out of 
context will probably be eliminated In the near future. 

Clearly, any variables which appear free In these LAMBDA 
expressions (perhaps as a result of their being compiled out of 
context) must be declared SPECIAL* 

5* Any variables appearing In arguments to F-type 
functions which are to be evaluated (e.g* the latter arguments 
to ARRAY) must Be declared SPECIAL* Unfortunately, here the 
compiler does no checking for the user* Hence, the user will 
lose if he does not heed this warning* Also, the user must 
remember to declare as SPECIAL any free variables appearing in 
functional position, or the compiler will take them to be 
undefihed functions and compile them as SUBRs. 

4* In his LISP code to be compi led, the user may redefine 
a LISP system function as a MACRO but not as an EXPft or EEXPR* 

If the user wishes the latter, e*g* to redefine SUBST via an 
EX PR, he may do the following instead; 

{PEFUN SUBST MACRO (X) (CONS 'SUBSTJ (CDR X)>) 

(DEFUN SU&STI EXPR * , ,) * 

(The atom ^EXPR' of course is unnecessary*) 
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111, Formatt-lng 

There are two functions available In the compiler for 
forma tti ng: FOftMFILE, analogous to CQMFILE, for formatting a 
file and FQRKAT> analogous to COMPILE, for formatting function 
definitions. Except for their obviously different purpose^ the 
syntax and semantics for these functions Is simitar to that for 
CWFILE and COMPILE, respectively, except that f JJ at present, 
FORrtFlLE has no n = C mode; til when n = I, the assumption 3? 
that the user wh£h availing CFORMFILE {fnJ fn£>) wishes to 
clobber the source file, i.e* wishes to give the target file the 
Same name as the source fi Ee. 


Please notify the author In case of compiler bugs or if you 
have other cofniitents to make. 


